This invention relates generally to the field of call processing and more particularly to providing service node/intelligent peripheral (SN/IP) telephony applications.
Computer-based telecommunications systems have grown exponentially over the last several years due, in part, to the ever-advancing and increasing availability of high-speed personal computers and low-cost equipment. The delivery and advancement of calling services has followed this trend of overwhelming growth. Because of rapid technological advancements, telephone service providers are now generally able to offer more complex calling services to a wider population and at a lower cost than previously possible. With this rapid advancement of technology and increasing consumer demand, telephone service providers realize the profitable potential to design, develop, and implement more sophisticated calling services.
During the current evolution of telephone network design, the industry developed a design architecture called Advanced Intelligent Network (AIN). AIN allowed calling service programming to finally be removed from the telephone switches. Prior to AIN, because of the complexity of telephone switches, every time a new calling service was developed, the switch vendors typically had to reprogram the switches to perform the service. This process normally delayed the introduction of new services and generally prohibited smaller telephone service providers from introducing their own calling services thereby reducing the possibility for competitive advantage.
AIN architecture generally works by grouping xe2x80x9cintelligentxe2x80x9d operations into peripheral computer systems, thereby freeing the switches to perform their core functions of call connection and call routing. AIN architecture also generally allows relatively inexpensive computer systems to provide flexible and efficient call processing. Because the intelligent peripheral computer systems are easier to update, reprogram, and maintain than switches, telephone service providers can generally offer a wider variety of calling services.
Calling services are typically delivered by AIN architecture through service control points (SCP). A switch sends a data package to the SCP which then manages the call processing. SCP""s usually delegate many of the tasks associated with the data package to intelligent peripherals (IPs). IPs generally provide a number of processing resources such as voice prompting and data collection. The SCP will normally defer a small part of the call processing to an IP, but will regain control immediately after the IP completes the task. In this prior art system model, the IP receives and executes only primitive commands such as Play Message or Collect Digits.
A typical contemporary AIN architecture system includes service nodes (SN). SNs are usually stand-alone platforms which independently deliver calling services. An SN is typically connected directly to a switch and is dedicated to deliver a particular calling service such as voice mail. After receiving a call, the switch directly routes it to the SN which then processes the call without much direction from the switch or SCP. SNs also may use IPs to provide primitive resources for call processing. Communication systems or calling service applications which use SNs and IPs together are commonly referred to as SN/IP applications.
A recent technological advance to the AIN architecture derives from a family of patents issued to Sattar et al., U.S. Pat. Nos. 5,469,500, 5,572,581, and 5,644,631. Sattar advanced the AIN architecture by establishing more coupling routines between SNs and IPs. The Sattar IP now typically performs more of the decision-making tasks previously handled by the SN. The SN is then left to perform the general call processing and the more complex decision-making tasks. In the context of calling service processing, this generally allows the SN/IP application to lessen fragmentation of the call flow. Call flow refers to the actual call connection between the user and the calling service and the control thereof.
The prior art in SN/IP applications, both before and after Sattar, uses a central program located on the SN which incorporates the call flow control, data access control, and asynchronous event handler. Data access control refers to the function of obtaining data from a source other than a user in response to a user input or call signal such as automatic number identification (ANI) or dialed number identification service (DNIS). The level of data access required depends on the particular calling service being provided. In a voice mail service, the data required would typically consist of a list of valid voice mailbox addresses to check against the user""s entry, a list of the user""s password or personal identification number (PIN) to check against the user""s entry, and the actual message(s) stored in the mailbox.
The asynchronous event handler refers to the call processing/decision-making functions. When a user initiates a call, the asynchronous event handler generally receives the call xe2x80x9cevent codexe2x80x9d and transfers it to the IP for interfacing with the telephony network. If an SN performs a certain function which requires data, the asynchronous event handler usually receives the xe2x80x9cget dataxe2x80x9d command and then either forwards control to the IP if the data is required from the caller or forwards control to the data access control to get data from another source. When the data returns, an event code is typically transferred back to the asynchronous event handler to determine which piece of call flow to execute next.
FIG. 1 shows a typical SN/IP model of the prior art. The system will typically include multiple SNs 100-103, each of which is dedicated to perform a different function. SNs of the same system will normally not be interconnected unless they are overlapped for redundancy. SNs 100-103 will generally be connected to multiple IPs 104-108 which interface with the telephone lines and, thus, also the voice path of the caller. A single SN 100 may be connected to several IPs 106-108, or may just be connected to one, depending on the system configuration and calling function. SNs 100-103 may also be connected to data access routine 109 to perform any data collection other than from the caller.
In an example of pre-Sattar operation, a caller places a call to check the balance in his/her checking account. SN 100 receives the call and forwards it to IP 108 to set up the interface between the calling service and the caller. Because this SN does balance checking, SN 100 begins call flow and sends the initial instruction, Play Message, to IP 108. When IP 108 plays the message, an event code is generated and control is forwarded back to SN 100. SN 100 stops the call flow and then sends the instruction, Get Account Number, to IP 108. Call flow begins again and the caller is prompted by IP 108 to enter the account number. When IP 108 gets the number entered by the caller, an event code is generated and sent back to SN 100. Call flow stops. SN 100 sends an instruction to the data access routine 109 to return a list of valid account numbers. Data access routine 109 returns the list for SN 100 to check against the entered account number. If the number is valid, SN 100 begins call flow again and sends IP 108 the instruction, Get PIN. The process continues until the service has been completed. With all control processing elements located in the SN, the call flow is fragmented because the application must always stop the call flow to return to the SN to perform a particular task or make a particular decision. This start/stop, back and forth methodology makes control of the call flow much more complicated from the programming aspect.
After Sattar, because IP 108 is now able to handle more complex tasks, SN 100 is able to send a string of commands, thereby increasing the length of call flow segments. When the caller places the call, SN 100 begins call flow and sends IP 108 the instructions, Play Message, Get Account Number, Is Account Number Valid?, Get PIN, Is PIN Valid? Call flow begins. IP 108 plays the message, prompts the caller for the account number and checks that number against an internal database. IP 108 then prompts the user for the PIN and checks that number against another internal database. IP 108 then generates an event code and sends the data back to SN 100. SN 100 stops call flow and then uses data access routine 109 to get the account balance corresponding to the account number. After obtaining the requested account balance information, SN 100 begins the call flow again and prompts IP 108 to play a message containing the account balance. In the Sattar model, the call flow presentation appears more linear than before.
A limitation of the prior art is that the system uses a central program to provide the call flow control, the data access control, and the asynchronous event handling. This centralization creates a complex, non-linear program. The call flow experienced by the caller is fragmented and scattered throughout the system. The Sattar patents help this by allowing larger segments of call flow to be kept together. Specifically, the IP portion of the program logic handles caller events and decisions, such as xe2x80x9cIs Account Number Valid?xe2x80x9d without intermixing those events and decisions with outgoing data access and asynchronous event handling program logic. However, the need for data access limits the length of the call flow segment that can be delegated to the IP. Each interaction by the caller with the data access control requires the call flow segment to end so the SN can use the caller information to retrieve more data. Only then can the SN reinitiate the next segment of call flow. This fragmentation makes programming and, therefore, maintenance of the system much more complex and expensive.
It would therefore be desirable to have a unified model for SN/IP applications which maintains continuous call flow as much as necessary and, thus, facilitates more linear programming of the system.
These features are achieved by a system and method for providing SN/IP applications which provide at least three distinct layers of concurrently operating control routines. This unified system comprises a first control layer, located on an SN, having an asynchronous event handler routine; a second control layer, located either on the same SN or a different one, having at least one data access routine; and a third control layer, located on an IP, having a call flow routine, wherein the third control layer is connected to the first and second control layers and wherein the IP provides the SN/IP applications with an interface to a telephony network. The present invention also provides for the asynchronous event handler routine and the call flow routine to operate concurrently.
The present invention produces the desired characteristics through a method for modeling SN/IP applications comprising the steps of implementing an event management function on an SN; implementing at least one data management function on an SN; implementing a call flow management function on an IP, wherein the call flow management function is connected to the event management function and to each of the data management function(s). Operating the event management function and the call flow management function concurrently.
It is an advantage of a preferred embodiment of the present invention to provide SN/IP applications by allowing the creation of programs as a set of nested routines running independently and concurrently on three different control layers. Because each layer focuses only on a particular portion of the overall calling service, that portion may be written or presented in a substantially linear fashion. This linear presentation generally keeps the call flow intact and greatly reduces the complexity of development and maintenance of the software.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.